Understanding Data Context and Successful Zero Trust Implementations in 5 Scenarios

The nature of business today is increasingly decentralized. Cloud applications are exploding. Data is everywhere. And a large number of users will continue to work remotely even post-COVID-19. While all of these things increase business agility, they also increase an organization’s attack surface. The concept of Zero Trust is generating a lot of buzz as a panacea for these new risk exposures—and for good reason. If implemented correctly, a security architecture designed around a Zero Trust ideology has the potential to protect against data breaches, ransomware attacks, and even insider threats. However, Zero Trust that is coarse-grained and too restrictive carries a higher potential for a failed implementation. 

The recent White House Executive Order on cybersecurity was drafted in response to escalating instances of data breaches and ransomware attacks. A continuous Zero Trust mindset is central to the advanced controls described by President Biden—as is the need to be more data-centric. This means that least-privileged access should be applied for every access decision—where the answers to the contextual questions of who, what, when, where, and how are critical for appropriately allowing or denying access to resources.

Why Zero Trust needs data context to succeed

If all you know is the user’s identity, you’re only going to get so far with Zero Trust. To apply successful controls that keep the business running while eliminating risks, you need more contextual information about both the user and the surrounding details involving how and why they’re interacting with the organization’s data and applications. This may include:

• What business group is the user in? 
• What’s their device posture—is it a managed versus unmanaged device? 
• What resources do they need access to? Is it a private application that they need to access a browser? Or do they need special protocol access to SSH because they’re a system administrator?
• Are they a contractor working on a project and do they need access to the corporate Office 365 account and specific content so they can collaborate with project stakeholders? 
• Once you grant them access, what are they doing? What activities are they trying to perform? Are they downloading data? Are they uploading data? Are they sharing data? Are they editing data? Or are they creating data? What is the sensitive nature of the data?

There are also several different activities that you also want to not only monitor but put Zero Trust controls around. I’ve put together five real-world scenarios where data context should inform the level of trust assigned to user access. They are as follows:

Scenario #1: Users need access to an internal or private application

The example here is a  user on the marketing team who just needs browser access to the company’s learning management system (LMS). But then a different user on the sysadmin team needs special SSH access so they can administer the server that runs the LMS application. 

The old way of managing application access has been to either make the app publicly accessible or to provide VPN access. But this kind of management leaves the opportunity for bad actors to gain access and move laterally. Even though both users are trying to access the same application, different contextual decisions need to be made about the level of access being granted to the LMS app based on the user’s specific business group. 

Scenario #2: User needs access to a popular, but high-risk, cloud storage app

Another user (also in marketing) wants access to a popular cloud storage application so they can quickly upload and share data. There are more than 2,400 cloud applications used in the average enterprise. A majority of those applications are used outside of IT, which means IT doesn’t have administrative access. The concern with using these kinds of Shadow IT apps is that they can introduce opportunities for data loss by careless employees or perhaps employees intending to steal data, simply because many of them lack adequate security capabilities. Do you really want sensitive data uploaded to one of these apps? In the past, IT managers simply blocked the use of cloud apps to cut off these attack vectors with blunt force. But the demands of business agility and the effects of digital transformation make coarse-grained access controls nearly impossible to enforce. 

This same user likes the app they have chosen because it’s really simple—they can just upload project data and share it directly with business partners. So the question is how do we include this kind of cloud application into a Zero Trust model? First, we need to understand not only who the user is and which device they’re using, but also the nature of the risk presented by the specific application. Is it well-known and widely used, or something brand new from a less-established developer? Has the app vendor implemented adequate security measures? We need to be able to calculate the contextual application risk. We also need to know what activity is being performed. Is the user simply accessing the app or are they performing an activity like an upload of sensitive company information?

Scenario #3: A risky user wants to download data

Let’s say you have a contractor whose contract is about to end with the company. This user goes into their corporate Office 365 account and downloads a bunch of data before they leave the company. Maybe they’re updating their work sample portfolio with publicly available documents, or maybe this is a malicious insider stealing sensitive information on their way out the door. 

In the past, access management was all or nothing. If the user in question is still an active contractor who needs data access to fulfill their day-to-day duties at the company, they’d probably have continuous access until the position officially ends. The old coarse-grained access controls are essentially just an on/off switch.

So how do you put more granular Zero Trust controls in place under these transitional circumstances? First, from an identity standpoint, we want to know that this is a contractor and not a full-time employee. That contextual difference can help flag that this might be a higher-risk scenario. Next, we want to know more about the specific activity that this user is performing. Are they trying to download data from one of our cloud applications? What do this user’s past activities tell us about this user’s risk profile? Has the user performed download activities like this before? We need to be able to evaluate the risk and enforce access controls based on these contextual factors.

Scenario #4: Unintentional or unapproved data movement between cloud app accounts

In this scenario, a user downloads data from the corporate cloud storage Office 365 OneDrive or Google Drive account and uploads that data to the same cloud storage app, but to an account not managed by IT. This may or may not be data theft. The user could be performing this data movement unintentionally, or perhaps it is an executive stealing trade secrets before they leave the company.  

Context is key in understanding the cloud app account details involved in both the download and the upload. Did the initial download take place from the corporate-managed Office 365 OneDrive account, and later on the same data was uploaded to an Office 365 OneDrive account not managed by IT? Or did the upload take place to the same corporate Office 365 OneDrive account because the user was collaborating on a project? Without the context of the instance of the cloud app, you would be forced to rely on mechanisms such as tenant restrictions supported by the cloud app vendors to simply block all Office 365 accounts except for the corporate account. This approach is not ideal as you could also be blocking productivity. For this use case, evaluating risk starts with understanding which cloud app instance is involved in the download and upload and then putting controls in place based on that contextual understanding to prevent risky activities and block sensitive data movement without slowing down user productivity.

Scenario #5: Sensitive data downloaded to an unmanaged device

The final scenario involves unmanaged devices—employees using their own machines (BYOD) or third-party contractors that don’t have a company-issued device, but they still need access to corporate applications to do their jobs. They may be a contractor that has an agreement with the company, but that may not be good enough to justify fully implicit trust. You need to give their device certain permissions, but what level of access is appropriate? 

In the old days, IT would only grant data and application access to the devices they controlled. With unmanaged devices, we may want to restrict the ability to download certain types of sensitive data. Knowing more about the device itself becomes a very important contextual input. 

Deploying Continuous Adaptive Trust with SASE

What all these scenarios point to is the need for data context in order to enforce the concept of Continuous Adaptive Trust. We need security that can analyze the facts of a specific situation and make real-time decisions about access controls based on the contextual risks presented. Who is the user? What is the posture of the device they are using? Where is the user located? What is the risk of the app they are accessing? Is it a corporate-managed cloud app, an app owned by one of the lines of business, or a partner’s app?  Or, is it the user’s personal cloud app account?  What activity is being performed?  Is sensitive data involved? These questions need to be asked when determining whether or not to grant initial access to the resource and also to continuously verify activities performed after the initial access. 

This is where a secure access service edge (SASE) architecture that supports Continuous Adaptive Trust is key. SASE is the delivery mechanism for Zero Trust and Continuous Adaptive Trust enables a more intelligent control point delivered by SASE. SASE enables you to move the Zero Trust control point to wherever the user and data are—wherever they go. This is very important today—with work-from-anywhere users accessing cloud resources, private applications, and websites beyond the on-prem view of IT, you need SASE’s ability to move the control point wherever users and data are. 

The fact is that our users and data are now everywhere. More than 50% of an organizations’ data is now in the cloud—and that includes an increasing amount of sensitive data. And unfortunately, most organizations are blind to cloud activities and cloud threats—like the current rise in cloud phishing where bad actors use cloud apps to host form data that is architected to harvest employee credentials. Ransomware is also on the rise—attacks have risen 150% and the amount paid by victims has increased more than 300%.

A SASE architecture is the natural evolution that shifts security to follow the nature of adaptive businesses—enabling intelligent, granular controls based on data context and eliminating risks to the organization. It implements a Zero Trust concept without restrictive rigidity that breaks under real-world circumstances.

This article was originally published by United States Cybersecurity Magazine.